1. Field of Invention
This invention relates generally to management of identity information held in directory servers in enterprise computer networks.
2. Prior Art
A typical identity management deployment for an organization will incorporate a directory service. In a typical directory service, one or more server computers host instances of directory server software. These directory servers implement the server side of a directory access protocol, such as the X.500 Directory Access Protocol (DAP), as defined in the document ITU-T Rec. X.519 “Information technology—Open Systems Interconnection—The Directory: Protocol specifications”, or the Lightweight Directory Access Protocol (LDAP), as defined in the document “Lightweight Directory Access Protocol (v3)”, by M. Wahl et al of December 1997. The client side of the directory access protocol is implemented in other components of the identity management deployment, such as an identity manager or access manager.
A directory access protocol follows a request-response model of interaction, in which the client establishes a connection to a directory server, and over that connection, sends one or more requests. The directory server processes those requests and sends responses over that connection. The types of requests in a directory access protocol include:                the bind request, in which the client sends its authentication information to the server,        the search request, in which the client requests one or more entries in the server's directory information tree be returned,        the modify request, in which the client requests that the set of attributes be changed in an entry in the server's directory information tree, and        the delete request, in which the client requests that an entry be removed from the server's directory information tree.        
In order to provide an anticipated level of availability or performance from the directory service when deployed on server computer hardware and directory server software with limits in anticipated uptime and performance, the directory service often will have a replicated topology. In a replicated topology, there are multiple directory servers present in the deployment to provide the directory service, and each directory server holds a replica (a copy) of each element of directory information. One advantage of a replicated topology in an identity management deployment is that even if one directory server is down or unreachable, other directory servers in the deployment will be able to provide the directory service to other components of the identity management deployment. Another advantage is that directory service query operations in the directory access protocol can be processed in parallel in a replicated topology: some clients can send queries to one directory server, and other clients can send queries to other directory servers.
Some directory server implementations which support the X.500 Directory Access Protocol also support the X.500 Directory Information Shadowing Protocol (DISP), as defined in the document ITU-T Rec. X.519, “Information technology—Open Systems Interconnection—The Directory: Protocol specifications”, which specifies the procedures for replication between directory servers that implement the X.500 directory access protocol.
In many large and multinational enterprises, the deployment might incorporate multiple distinct implementations of a directory server, and there may be directory server implementations that are not based on the X.500 protocols. Examples of directory server implementations that are not based on the X.500 protocols include the Microsoft Active Directory, the Sun Java Enterprise System Directory Server, OpenLDAP directory server, and the Novell eDirectory Server. As there is currently no standard replication protocol between directory server implementations from different vendors that are not both implementing the X.500 protocols, synchronization mechanisms are often used in addition to replication protocols in order to maintain the consistency of directory information between directory servers in the deployment. Synchronization products, such as a metadirectory server, are used in enterprise identity management deployments that incorporate directory server implementations from multiple vendors. These synchronization products interconnect these directory servers, and transfer changes made in one directory server to another directory server, so that all directory servers have copies of the data.
A primary component of the information model of a directory server is the directory information tree. The directory information tree comprises a set of one or more directory entries. Each entry has a distinguished name that is unique amongst the entries in the directory information tree. Each entry comprises a set of one or more attributes. Each attribute has an attribute type, and there is at most one attribute in an entry of each attribute type. Each attribute has one or more values. Each entry has an attribute, objectClass, with one or more values that are names of object classes defining the contents of the entry.
A directory schema defines the semantics associated with each object class and attribute type. The schema specifications for an object class include: the attribute types of attributes which must be present in an entry when the entry has that object class, and the attribute types of attributes which may be present in an entry when the entry has that object class. The schema specifications for an attribute type include: the maximum number of values of the type which can be present in an entry, the syntax of the values of the attribute type, and how values of the attribute are compared with each other. The directory schema is represented in the directory as values of the two operational attributes attributeTypes and objectClasses, as described in the document “Lightweight Directory Access Protocol (LDAP): Directory Information Models”, by K. Zeilenga, of June 2006.
The choice of schema to use in a directory server is determined by the administrator of the directory server. Some directory server implementations have a single, fixed schema; others are extensible and permit the administrator to add attribute type and object class definitions. Several recommended schemas have been published, including the documents ITU-T X.520|ISO/IEC 9594-6, “The Directory: Selected attribute types”, ITU-T X.5211 ISO/IEC 9594-7, “The Directory: Selected object classes”, “Definition of the inetOrgPerson LDAP Object Class” by M. Smith of 2000, “Lightweight Directory Access Protocol (LDAP): Directory Information Models” by K. Zeilenga of Jun. 2006, and “Lightweight Directory Access Protocol (LDAP): Schema for User Applications”, by A. Sciberras of June 2006. In each of these schemas, a user of directory-enabled applications is represented by a single entry. The set of allowed attributes of the object class for such an entry include an attribute which comprises the authentication credentials of the user, such as the user's password. For example, the ‘inetOrgPerson’ object class allows the attribute userPassword, which contains the password of the user represented by an object of that class.
A metadirectory, as described in U.S. Pat. No. 7,191,192 B2 to Yellepeddy et al, is a software product which translates the contents of one data repository to be appropriate for use in another repository, in which the data repositories may be directory servers or other forms of databases. One primary use of a metadirectory is the translation of directory entries from one schema to another, for deployments in which two or more implementations of directory servers are present, and the directory servers have fixed incompatible schemas.
A directory proxy server is a specialized server which implements a directory access protocol, typically LDAP, but does not maintain a copy of the directory information tree. Instead, the directory proxy server will forward requests it receives to one or more other directory servers for further processing.
A directory server and a directory proxy server typically generate access logs in a text file or in a relational database, and these access logs have one log record for each request received by the directory server or directory proxy server.
A directory-enabled access control system comprises a set of middleware components which rely upon a directory server to maintain information about the users in an enterprise, in particular each user's authentication credentials and access rights.
Typically, an implementation of a directory-enabled access control system in the prior art will, when a user attempts to authenticate by providing their name and credential, send a search request to a directory server to locate the entry for that user. If an entry is found for that user, then the implementation either may read an attribute containing a credential from the returned directory entry and compare that credential with a credential presented by the user, or the implementation may send a bind request to the directory server to perform the comparison, in which the bind request comprises the distinguished name of the entry and the credential supplied by the user.
3. Objects and Advantages
Some existing implementations of directory-enabled access control systems update a user's directory entry when that user successfully logs in, by sending a modify request to the directory for the entry corresponding to the user. That modify request will cause the directory server to replace an attribute in that user's entry which represents the user's last login time with the current date and time. The limitations of this prior art approach include:                Unlike processing a search or bind request, a directory server processing a modify request must write the change to disk storage, which will increase latency and response time in processing authentication.        Many enterprise directory service deployments have a distributed directory service, in which many directory servers replicate the same content, either through a directory replication protocol such as DISP or through a metadirectory. A directory server which processes a modify request must replicate this change to all other directory servers in the deployment, and this may lead to poor directory server performance and high network utilization when there is a large community of users represented in the database. Furthermore, in deployments implementing multi-master replication (MMR), should two or more modifications be sent to more than one directory server for the same entry, the MMR algorithm implemented by the directory servers may detect a conflict between the modifications, and correct the conflict by replacing the value with a value for the last login date that is not the most recent date among the conflicting values.        Many schemas do not define an attribute for representing a user's last login time.        Since, as a search request or a bind request does not update the target user's entry, when directory-enabled access control systems that only send search and bind requests (and no modify requests) to the directory to authenticate a user are part of a deployment, it is not possible to read from a user's entry any attribute that would indicate when a user last logged in.        
It is an advantage of this invention that it can detect authentication attempts performed by the access control component which are realized as search requests.
It is an advantage of this invention that it does not incorrectly categorize a user as having an inactive account should a network partition prevent the records for authentications from that user at a directory server from being transferred to the unused account detection component.